Public Health Surveillance

Surveillance is the systematic collection, analysis and interpretation of health data for action. The architectural requirement that distinguishes it from routine reporting is timeliness under uncertainty: a signal that arrives six weeks later, correct and complete, is worth less than an imperfect signal that arrives in two days.

Two systems, not one

	Indicator-based	Event-based
Source	Routine reporting from facilities and laboratories	Anything: rumours, media, community reports, hotlines, clinician calls
Structure	Structured, defined indicators and case definitions	Unstructured, heterogeneous
Cadence	Weekly, monthly	Continuous
Strength	Trends, comparability, denominators	Speed, detects the unexpected
Weakness	Slow; only sees what is already defined	Noisy; requires triage capacity
Architecture	HMIS/DHIS2, case reporting, laboratory feeds	Intake channels, triage workflow, verification tracking

Both are needed. Event-based surveillance detects the outbreak; indicator-based surveillance characterises and tracks it. A country with only the first cannot measure; with only the second, it finds out late.

The reporting chain

   Clinical encounter
        │  suspected case meeting a case definition
        ▼
   ┌────────────────────────────────────────────────┐
   │  Detection                                     │
   │   · in-EMR alert on a coded diagnosis          │
   │   · CHW danger sign / community report         │
   │   · laboratory positive result                 │
   └───────────────────┬────────────────────────────┘
                       ▼
   ┌────────────────────────────────────────────────┐
   │  Case report — individual level, identified     │
   │   demographics · clinical · exposure · location │
   └───────────────────┬────────────────────────────┘
                       ▼  via the interoperability layer
   ┌────────────────────────────────────────────────┐
   │  Surveillance system                           │
   │   deduplicate · classify (suspected/probable/  │
   │   confirmed) · link laboratory results         │
   └──────┬──────────────────────┬──────────────────┘
          ▼                      ▼
   Investigation and       Aggregation, dashboards,
   response workflow       trend analysis, alerting
   (contacts, isolation)

Automated detection from coded data is the highest-leverage improvement available in most systems: when a clinician records a notifiable diagnosis in the EMR, the case report should be generated rather than depending on the clinician remembering to complete a separate paper form. This requires the diagnosis to be coded against a value set of notifiable conditions — which is a terminology problem before it is a surveillance one.

Case definitions change, and the architecture must cope

During an emerging outbreak, the case definition changes — sometimes weekly. Cases previously classified as suspected become probable; testing criteria broaden.

Architectural requirements:

Version case definitions, with effective dates
Store the raw clinical data, not only the derived classification, so cases can be reclassified retrospectively under a new definition
Record which definition version produced each classification
Expect the reporting form to change — a system where adding a field takes a release cycle is unusable in an outbreak

Point 2 is the one that repeatedly causes problems. A surveillance system storing only "probable case" cannot re-derive counts when the definition changes, and the epidemic curve becomes uninterpretable.

Laboratory linkage

Confirmation comes from the laboratory, and linking a specimen result back to the case report is where surveillance systems most often break.

Specimen identifiers must be carried through: from the clinical request, onto the specimen, into the laboratory system, and back with the result. Barcodes, and a specimen identifier distinct from the patient identifier.
Results must be coded — LOINC for the test, SNOMED CT or a defined value set for the result — or automated classification is impossible.
Unmatched results are inevitable and need a reconciliation queue with an owner.
Genomic surveillance adds sequence data with its own identifiers, repositories and turnaround times; the linkage requirement is the same and the latency is longer.

FHIR: ServiceRequest → Specimen → Observation / DiagnosticReport.

Surveillance types and their architectural demands

Type	Demands
Case-based (notifiable disease)	Individual-level reporting, deduplication, laboratory linkage, investigation workflow
Syndromic	High-volume, low-specificity data from routine encounters; needs coded presenting complaints and baseline modelling
Sentinel	A defined subset of sites reporting in depth; needs a clear site register and denominators
Laboratory-based	Direct feeds from laboratory systems; the fastest confirmation channel
Genomic	Sequence data linked to case data; specialised repositories, long turnaround
Wastewater / environmental	Sampling site registry, non-person-linked; independent of care-seeking, which is its main advantage
Mortality	Civil registration linkage; often the slowest and most complete signal
Event-based	Intake from many informal channels, triage and verification workflow

Aggregation and analysis

Denominators are the recurring problem: catchment populations, projected from a census that is years old, and disputed. Publish the denominator source with every rate.
Thresholds and alerting — epidemic thresholds by disease and season, aberration detection algorithms. Tune for the false-positive rate the investigation team can actually absorb; an alerting system that cries wolf gets muted.
Geographic analysis — see GIS. Case location, facility location and residence location are three different things and are constantly conflated.
Timeliness metrics — measure the system itself: onset to presentation, presentation to report, report to investigation, investigation to response. These are the numbers that show whether surveillance is working.

Privacy

Surveillance is the clearest case where individual-level identified data is processed without individual consent, under a legal mandate. That makes the boundaries important:

Narrow legal mandate. Notifiable conditions are enumerated in law. "Surveillance" is not a general authorisation to collect health data.
Purpose limitation, enforced technically. Surveillance data must not flow to immigration, policing or employment. Where it has, the consequence is that affected communities stop presenting for care — which defeats the surveillance.
Small-cell suppression in published outputs.
Retention limits for identified case data after the investigation closes.
Audit of who accessed identified case data.

See consent and trust.

Platforms

Platform	Role
DHIS2	Aggregate surveillance reporting, and case-based via Tracker; the most common national choice
SORMAS	Outbreak and case management, contact tracing; open source
Go.Data (WHO)	Outbreak investigation and contact tracing
EpiInfo (CDC)	Analysis and rapid form building
OpenELIS Global	Laboratory results feeding surveillance
Event-based intake	Usually built locally, or on a general case-management tool

FHIR has relevant content in electronic case reporting work, primarily US-originated; check applicability before adopting.

Checklist

References

WHO surveillance resources — https://www.who.int/emergencies/surveillance
WHO Integrated Disease Surveillance and Response guidance — https://www.afro.who.int/health-topics/integrated-disease-surveillance
SORMAS — https://sormas.org/
WHO Go.Data — https://www.who.int/tools/godata
DHIS2 — https://dhis2.org/
GIS, terminology services

Two systems, not one​

The reporting chain​

Case definitions change, and the architecture must cope​

Laboratory linkage​

Surveillance types and their architectural demands​

Aggregation and analysis​

Privacy​

Platforms​

Checklist​

References​